<?php
/**
 * <https://y.st./>
 * Copyright © 2018 Alex Yst <mailto:copyright@y.st>
 * 
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 * 
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 * GNU General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with this program. If not, see <https://www.gnu.org./licenses/>.
**/

$xhtml = array(
	'<{title}>' => 'Cancelled',
	'takedown' => '2017-11-01',
	'<{body}>' => <<<END
<img src="/img/CC_BY-SA_4.0/y.st./weblog/2018/05/03.jpg" alt="Flowering cherry flowers" class="framed-centred-image" width="649" height="480"/>
<section id="shorts">
	<h2>Shorts</h2>
	<p>
		As I may or may not have mentioned, the air conditioning at work has been broken for a while.
		And we often work with three flame-powered ovens turned on.
		And summer is approaching in this hemisphere.
		So anyway, it&apos;s been pretty hot and unpleasant.
		The head manager&apos;s been working with a repairperson, but today, it looks like the two have decided it&apos;s going to take much more time to get the thing running than previously anticipated.
		As such, the head manager says that starting tomorrow, we can all wear shorts!
		Normally, we&apos;re not allowed to wear them at work until around June, if I recall.
		In my opinion, getting to wear shorts is better than any air conditioning.
		I&apos;d actually rather wear shorts at work even in the winter though because of how easily I overheat.
		I mean, even in the winter, we still have three flame-powered ovens to deal with.
	</p>
</section>
<section id="instruction">
	<h2>Driving instruction</h2>
	<p>
		My driving instructor cancelled on me.
		This time for good.
		It seems their brake pads are worn out and they&apos;re not going to get replacements for a while.
		Being new at driving, they don&apos;t want me breaking anything while the car is in that state.
		I&apos;m not sure how long &quot;a while&quot; is, but I have to assume it&apos;s more than a couple weeks by the way they put it.
		By the time they&apos;ve got new break pads, my time will either be up or there won&apos;t be enough time left for me to finish getting comfortable behind the wheel.
		My main issue is that I need experience, not that I have a tonne more to actually take in, so this isn&apos;t something I can rush really.
	</p>
</section>
<section id="drudgery">
	<h2>Drudgery</h2>
	<p>
		My discussion post for the day:
	</p>
	<blockquote>
		<h3>$a[ARP], the Address Resolution Protocol</h3>
		<p>
			In $a[ARP], the sending node uses a broadcast packet, so all nodes on the $a[LAN] receive the message.
			This message contains a request for a reply from whatever node has the intended recipient&apos;s $a[IP] address.
			The request contains the sender&apos;s $a[IP] address, the sender&apos;s $a[LAN] address, and the intended recipient&apos;s $a[IP] address.
			If a node with the intended recipient&apos;s $a[IP] address exists on the local network, it&apos;ll reply, sending its $a[LAN] address.
			Because the initial request contains the addresses of the sending node, the intended recipient is able to reply directly to the querying node and doesn&apos;t have to broadcast the response.
		</p>
		<p>
			Nodes maintain $a[ARP] caches to keep track of recent $a[IP] address/$a[LAN] address pairs discovered.
			However, entries expire on modern Linux systems after about thirty seconds; in systems of old, expiration would take about ten minutes.
			When the broadcast reaches the intended recipient, that node adds the sender&apos;s addresses to its cache.
			However, strangely, an unintended recipient only updates the existing entry for the sender&apos;s information.
			If no such entry yet exists, the unintended recipient doesn&apos;t add one.
			Furthermore, expired entries, if needed, are usually first sent the $a[LAN] address request via unicast, not multicast.
			If the node at that $a[LAN] address turns out not to still have that $a[IP] address (or that node is missing), the request can be retried as a broadcast request.
			The unicast-based request is more like a refresher to see if the network is still in the last-known state or if something has changed.
			However, reverifying via unicast is technically optional, so some nodes may fail to perform this optimisation.
			In cases where a node is on the network but not connected directly, the node it&apos;s connected through acts as a proxy and will respond to $a[ARP] requests on the indirectly-connected node&apos;s behalf.
		</p>
		<p>
			$a[ARP] can also be used for address conflict detection, though in practice, it doesn&apos;t tend to be correctly implemented.
			Once a duplicate address is detected, the newly-added (or awakened) node with the duplicate address should change its address or request a new address from $a[DHCP] if $a[DHCP] is used.
			However, typically, the error is simply logged and no meaningful action taken.
			$a[RFC] 5227 lays out a specific method of using $a[ARP] to detect and address conflicts and find a new address that doesn&apos;t conflict with those of other nodes called Address Conflict Detection.
		</p>
		<p>
			$a[ARP] spoofing is pretty easy; a node simply waits until the node it wishes to impersonate is down (or it <strong>*knocks*</strong> it down with a $a[DoS] attack), then responds to $a[ARP] requests pretending to be the node.
			By doing that, the attacking node steals the $a[IP] address of the downed node.
			From there, nodes wishing to communicate with the downed node will communicate with the attacker instead by mistake.
			Clearly, $a[ARP] wasn&apos;t designed with security in mind.
			Encryption keys such as $a[SSH] keys and $a[TLS] certificates can&apos;t be impersonated this way, but many users don&apos;t check the credentials of keys like would be necessary to realise an attack was underway (Dordal, 2014).
		</p>
		<p>
			It&apos;s worth mentioning that you can check out your $a[ARP] cache by using the <code>ip -s neigh</code> command on the command line.
			At the time of writing this, my $a[ARP] cache only contains one entry, ostensibly that of the router.
			I don&apos;t currently have my home server set up, so the only node my laptop needs to communicate with is that of the outbound gateway; that is, that of the Wi-Fi router.
			If you&apos;re on a non-Linux system, a different command may be needed to check out your $a[ARP] cache.
			For example, the book mentions that the Windows command is <code>arp -a</code>, though I haven&apos;t tested this, as I&apos;m a Debian user.
		</p>
		<h3>Neighbour Solicitation</h3>
		<p>
			Like $a[ARP], Neighbour Solicitation involves broadcasting a request for identification to several hosts and hoping one responds.
			However, unlike $a[ARP], Neighbour Solicitation uses a special solicited-node multicast address, which usually refers to a smaller group of machines.
			For this reason, Neighbour Solicitation usually doesn&apos;t reach as many machines as $a[ARP].
			The group is smaller because for a given node to be included in the broadcast-to list, it needs to specifically subscribe to that solicited-node multicast address.
			Nodes are supposed to subscribe to specific solicited-node multicast addresses based on the least-significant 32 bits of their $a[IP] addresses, so using those addresses to locate a given host almost pinpoints the host even before sending the request.
			Very few (if any) unintended recipients will receive the request.
			If the node with the correct address receives the request, it replies with a Neighbour Advertisement; a node may also send out a Neighbour Advertisement if it thinks its network address has changed.
		</p>
		<p>
			Like with $a[ARP] requests, when stale in the cache, entries are first reverified via a unicast request.
			However, unlike with $a[ARP], this isn&apos;t an optional part of the protocol.
			Neighbour Solicitation also allows proxy responses like $a[ARP] does.
			However, Neighbour Solicitation improves upon the concept by including a flag that marks proxy responses.
			If the thought-to-be-remote node turns out to be on the network and sends a Neighbour Advertisement, the Neighbour Advertisement sent by the proxy will be ignored.
		</p>
		<p>
			Neighbour Solicitation also includes a tool for determining whether a previously-accessible node has become unreachable: Neighbour Unreachability Detection.
			If traffic is flowing to or from the node, the node is known to still be reachable.
			Likewise, if it&apos;s responding to the occasional Neighbour Solicitation requests, it&apos;s known to be reachable.
			Otherwise, a node not getting responses and not seeing traffic to/from another node will take appropriate action.
			If the lost node is a neighbouring host, the node may try to find the node again using a multicast request for Neighbour Solicitation.
			If the neighbour&apos;s $a[IP] address has simply changed, this&apos;ll allow the node to find it once more.
			If the missing node is instead a switch, the node will find another route (if one exists) to send traffic through the network.
		</p>
		<p>
			Lastly, the Neighbour Solicitation protocol includes a way to inform a node that another node is a better choice for delivering packets to a given destination.
			In $a[IPv4], this functionality isn&apos;t handled by $a[ARP], but instead by $a[ICMP].
		</p>
		<p>
			Like $a[ARP], the Neighbour Solicitation protocol relies on trusting other nodes, which makes it inherently insecure.
			For example, a host can pretend to be a router by simply <strong>*claiming*</strong> to be a router.
			Any traffic another node attempts to send through the false router can then be intercepted and/or altered.
			Any unencrypted packets will be compromised.
			(This is a great example of why <strong>*all*</strong> network traffic should be encrypted.)
			Like with $a[ARP], a malicious host can also knock another host offline, then claim to be that host itself.
			Also like with $a[ARP], these sorts of attacks only work within the $a[LAN], not from remote networks, but there are a number of reasons this is still a hazard.
			Examples given by the book include open Wi-Fi (in which any host is allowed to join the $a[LAN]) and viruses.
			Viruses typically aren&apos;t a threat for operating systems with decent security, such as Linux, but Linux viruses can and do exist.
			(Any computer that allows its user to run arbitrary third-party software opens itself to the possibility of viruses.
			Any computer that doesn&apos;t though, fails to be very useful at all.)
			On a Windows-based network though, this is a much more likely threat.
			It&apos;s also worth mentioning that it only takes one compromised machine to cause the attack; only one insecure computer need catch the virus to cause problems for all hosts on the $a[LAN].
			Authentication Headers or Encapsulated Security Payload Headers can be used to prevent such attacks, but they don&apos;t work for many situations.
			Each machine must be statically configured, which as the book says, doesn&apos;t scale well.
			No automatic configuration is possible, so this option doesn&apos;t work for preventing attacks within an open Wi-Fi $a[LAN].
			An alternative to Neighbour Discovery, Secure Neighbour Discovery, is an option.
			However, it&apos;s based on public key encryption.
			It can be detected if a node is now communicating with a different node than before, but which one is the imposter: the first node seen or the second?
			A $a[PKI] can be used, but this causes further issues.
			The concept of certificate &quot;authorities&quot; is incredibly shaky at best.
			Specific certificated have to be set up as magically trusted, but certificate &quot;authorities&quot; have been known to grant false certificates that allow impersonation of other parties in the past.
			It doesn&apos;t happen often, but it&apos;s a non-zero risk.
			This trust in certificate &quot;authorities&quot; forms the weak leak of the trust tree, yet it&apos;s also the most vital link.
		</p>
		<p>
			Secure Neighbour Discovery also supports cryptographically-generated addresses.
			These addresses are nearly impossible to spoof, as they&apos;re verifiable against a hash of several known pieces of information including the cryptographic key, but if you&apos;re familiar with $a[Tor] ($a[Tor] uses cryptographically-generated addresses as well), you should know the drawback to these addresses: they&apos;re not human readable.
			For example, one of my $a[Tor]-based onion addresses (currently inactive) is <a href="https://y.st./en/domains/nfcbk2sgyblvdnq3.onion.xhtml"><code>nfcbk2sgyblvdnq3.onion</code></a>.
			Is that a host name you could remember?
			It&apos;s not one I can remember.
			The $a[Tor] community has developed software for generating certificates with partial hash collisions, allowing you to choose part of your host name, but you still can&apos;t choose the whole thing (if you could, the benefits of cryptographically-generated addresses would be lost) and I don&apos;t think a similar tool for Secure Neighbour Discovery exists.
			Then again though, the hash-based addresses used by Secure Neighbour Discovery are $a[IPv6] addresses.
			Only base-16 characters are allowed anyway and the addresses aren&apos;t meant to be readable.
			The important thing is that by using cryptographically-generated addresses, it becomes impossible for a node to spoof an address, as it doesn&apos;t have the private key needed to sign anything in a way that&apos;d be verifiable with a public key that has the right hash value.
			Unfortunately, Secure Neighbour Discovery doesn&apos;t see much use, both because $a[IPv6] still sees little use and because people think the vulnerabilities Secure Neighbour Discovery protects against are too difficult to exploit to be worth setting up a defence against (Dordal, 2014).
		</p>
		<div class="APA_references">
			<h3>References:</h3>
			<p>
				Dordal, P. (2014). 7 IP version 4 - An Introduction to Computer Networks, edition 1.9.10. Retrieved from <a href="https://intronetworks.cs.luc.edu/current/html/ipv4.html"><code>https://intronetworks.cs.luc.edu/current/html/ipv4.html</code></a>
			</p>
			<p>
				Dordal, P. (2014). 8 IP version 6 - An Introduction to Computer Networks, edition 1.9.10. Retrieved from <a href="https://intronetworks.cs.luc.edu/current/html/ipv6.html"><code>https://intronetworks.cs.luc.edu/current/html/ipv6.html</code></a>
			</p>
		</div>
	</blockquote>
</section>
<section id="ranch">
	<p>
		I now have a bigger jar at my disposal: the jar from the bigger size of vegan mayonnaise.
		The bulk size makes it a little cheaper.
		I&apos;m going to start using half jars of mayonnaise in my recipe, for ease.
		There&apos;s about 900 grams of mayo in these jars according to my scale, I&apos;ll base the recipe on 450 grams of mayo.
		I tried a new ratio for the ingredients today, but I used too much salt.
		The problem is that my scale won&apos;t measure anything less than three grams, so I had to use no less than three grams of salt.
		There&apos;s got to be another way.
		Anyway, my work-in-progress recipe is as follows:
	</p>
	<ul>
		<li>
			450 grams of vegan mayonaise
		</li>
		<li>
			10 grams of onion powder
		</li>
		<li>
			10 grams of garlic powder
		</li>
		<li>
			10 grams of dried dill
		</li>
		<li>
			5 grams of dried parsley
		</li>
		<li>
			3 grams of salt
		</li>
		<li>
			40 grams of distilled white vinegar
		</li>
		<li>
			50 grams of soy milk
		</li>
	</ul>
</section>
END
);
